Conversation
Implement GET /api/v1/beacons/manifest to build and return the full manifest JSON (language, region, tags, providers with nested topics and files, totals, checksum). Implement HEAD support with If-None-Match (304 Not Modified) and If-Match (412 Precondition Failed) for lightweight change detection during sync. Manifest versioning uses lazy evaluation: content checksum is compared with stored value on the beacon, and the version is incremented only when content actually changes. Conditional requests use the stored version directly, avoiding a full manifest build for 304/412 responses. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Introduce Beacons::RebuildManifestJob and wire it into Topics::Mutator (create, update, archive, unarchive, destroy), BeaconTopic/BeaconProvider join model callbacks, and SynchronizeCognatesOnTopicsJob so that beacon manifests stay current without waiting for a GET request. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
|
|
||
| # During sync, beacon sends If-Match with its current version. | ||
| # If the manifest changed since sync started, return 412 so beacon aborts and restarts. | ||
| if stale_by_match?(stored_etag) |
There was a problem hiding this comment.
Couple of checks here to protect from unnecessary rebuild
| belongs_to :beacon | ||
| belongs_to :provider | ||
|
|
||
| after_commit :rebuild_beacon_manifest, on: [ :create, :destroy ] |
There was a problem hiding this comment.
When we add controller/mutator for managing association, move this logic there
| belongs_to :beacon | ||
| belongs_to :topic | ||
|
|
||
| after_commit :rebuild_beacon_manifest, on: [ :create, :destroy ] |
There was a problem hiding this comment.
When we add controller/mutator for managing association, move this logic there
There was a problem hiding this comment.
Could this logic go in a concern shared by the two models?
There was a problem hiding this comment.
It will not stay in models. It will go to controller/mutator when we add managing associations
|
Some nice things we might want to store for the admins are some statistics on the current deployed manifest as well as the upcoming version. So we can have some nice summary facts like: |
|
We can store manifest itself inside beacon model. It will help to show total files number or size. I will save manifest into beacon |
|
How about storing statistics on the most recent deployed manifest? Size, Number of files, etc? Then we can just do some math and compare. |
Save the manifest content (without version/checksum metadata) as jsonb on the beacon record so admins can inspect the full manifest state. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Rotate manifest_data into previous_manifest_data before saving new content, so admins can compare current and previous manifests. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
|
Added |
| ::Beacons::ManifestBuilder.new(Current.beacon) | ||
| end | ||
|
|
||
| def stale_by_match?(etag) |
There was a problem hiding this comment.
I'm wondering if the naming could be a little clearer here, maybe version_mismatches?.
There was a problem hiding this comment.
But it is important to underline here that version can become stale during process. And later that is can be outdated. Just match/mismatch does not cover that these are different checks. But I am open to better naming for sure
There was a problem hiding this comment.
Could go with sync_version_stale? and cached_version_fresh?.
| if_match != etag | ||
| end | ||
|
|
||
| def fresh_by_none_match?(etag) |
There was a problem hiding this comment.
Same here, could we go for something like version_matches?.
| belongs_to :beacon | ||
| belongs_to :topic | ||
|
|
||
| after_commit :rebuild_beacon_manifest, on: [ :create, :destroy ] |
There was a problem hiding this comment.
Could this logic go in a concern shared by the two models?
3 participants
Implement GET /api/v1/beacons/manifest to build and return the full manifest JSON (language, region, tags, providers with nested topics and files, totals, checksum). Implement HEAD support with If-None-Match (304 Not Modified) and If-Match (412 Precondition Failed) for lightweight change detection during sync.
Manifest versioning uses lazy evaluation: content checksum is compared with stored value on the beacon, and the version is incremented only when content actually changes. Conditional requests use the stored version directly, avoiding a full manifest build for 304/412 responses.
What Issue Does This PR Cover, If Any?
Resolves
#566
#567
#573
What Changed? And Why Did It Change?
How Has This Been Tested?
Rspec
Please Provide Screenshots
Additional Comments
For changed associations (such as topic/providers) rebuild is triggered from callbacks now.
This logic should be later moved into controllers/mutators.